Pharmacy Benefits Management Method and Apparatus 

RELATED APPLICATION DATA 

[0001] This application claims benefit of United States provisional patent 
application Ser. No. 60/190,556 filed on March 20, 2000, the disclosure of which 
is incorporated herein by reference. 

[0002] BACKGROUND 
[0003] Field of the I nvention : 

[0004] The invention relates to pharmacy benefits and more particularly to a 
system and method for managing pharmacy benefits to permit costs to be 
reduced. 

[0005] Description of the Related Art: 

[0006] Health care costs in the United States have risen dramatically over the 
past several decades. In 1999, health care spending accounted for 13 percent of 
the GDP. In the United States, most health care is delivered through employer 
sponsored health care plans, such as Health Maintaining Organizations (HMOs). 
The basic premise of an HMO is to permit the health care benefit delivered to 
patients, i.e. recipients, to be "managed" in order to reduce costs. 

[0007] Prescription drugs are marketed and delivered in a unique manner with 
respect to other health care benefits. Accordingly, management, and thus cost 
reduction, of prescription drug benefits has historically been approached 
differently* Typically, Pharmacy Benefit Managers (PBMs) have been used to 
process claims for prescription drug benefits and attempt to control costs. PBMs 
ordinarily are entities that are independent of the benefit provider, e.g. an 
insurance company, and contract with the benefit provider to process claims for 
pharmacy benefits. 

[0008] However, costs for prescription drugs has grown faster than any other 
expenditure for health care costs in recent years. In 1999 alone, spending for 
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prescription drugs in the United States rose nearly 17 percent to 
$100,000,000,000.00 and is projected to continue to increase faster than any 
other category of health care costs over the next decade. Currently, 
expenditures for prescription drugs account for over 20 percent of the budget for 
many health care plans. It is clear that the use of PBMs, and other efforts to 
reduce health care spending have not been effective in reducing expenditures for 
prescription drug benefits. 

[0009] PBMs ordinarily develop "formularies", i.e. a lists of drugs in specific 
classes that will be given favorable treatment. For example, the formulary may 
specify only a single particular drug in a class of drugs which can be prescribed 
under a particular pharmacy benefit plan or may classify tiers of drugs in order of 
preference. In some cases, the formulary directs the patient to the lowest cost 
drug. However, PBMs often operate under agreements with prescription drug 
manufacturers which include complex rebate plans. Accordingly, it is not always 
clear if the formulary will result in delivery of the appropriate prescription drug 
that is truly lowest in cost to the patient, through deductibles and copayments, 
and to the prescription drug benefit provider, such as an HMO. 

[0010] Further, the distribution channels for prescription drugs in most cases 
are totally separated from the payment channels. For example, a patient may be 
diagnosed by a physician as having a condition that requires medication. The 
Physician then decides on a class of drugs appropriate for treatment of the 
diagnosed condition and prepares a prescription for one of plural drugs in that 
class. The patient then takes the prescription to a pharmacy for dispensing of 
the prescription drugs. If the patient has a prescription drug benefit, e.g. through 
health insurance coverage, the pharmacist will utilize the PBMs computer system 
to apply the formulary associated with that patient's benefit plan, dispense the 
prescribed drug, collect any deductible payment or copayment from the patient in 
accordance with the formulary and benefits structure of the applicable plan, and 
submit claims documentation to the claims processor, such as a PBM, to collect 
the remaining cost for the dispensed drugs. 
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[0011] Significantly, the patient and doctor ordinarily are not aware of the 
costs of the dispensed drugs and costs of alternatives thereto before, during, or 
after dispensing of the drugs. Further, the provider of the drug benefit, such as 
an employer or HMO are not aware of this information at the point of purchase 
either. Accordingly, prescription drugs are dispensed without consideration for 
direct costs. The choice amongst alternatives is made solely by the physician 
without knowledge of any cost effects for the patient of the benefits provider. 
Often the creator of the formulary has direct economic interests that may not ally 
with those of the patient and benefit provider. The PBM or other entity 
processing pharmacy benefit claims has cost information and other relevant 
information. However, this information often is used primarily to drive markets to 
profitable products and is often obfuscated by complex rebate algorithms. Such 
information is not available to the patient or their physician at the time of making 
drug therapy decisions. Therefore, costs are not always minimized for drug 
benefits and thus the drug benefits are not managed well. 

[0012] Recent advances in communication, the Internet in particular, have 
facilitated on-line distribution of various information. In fact, some of the 
pharmacy information described above has been exchanged over the Internet. 
The Internet is a worldwide network of computers linked together by various 
hardware communication links ail running a standard suite of protocols known as 
TCP/IP (transmission control protocol/Internet protocol). The growth of the 
Internet over the last several years has been explosive, fueled in the most part by 
the widespread use of software viewers known as browsers and HTTP (hypertext 
transfer protocol) which allow a simple GUI (graphical user interface) to 
communicate over the Internet. Browsers generally reside on the computer used 
to access the Internet, i.e. the client computer. HTTP is a component of TCP/IP 
and provides users access to files of various formats using a standard page 
description language known as HTML (hypertext markup language), and more 
recently XHTML (extensible hypertext markup language). The collection of 
servers on the Internet using HTTP has become known as the "World Wide Web" 
or simply the "Web." 
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[0013] Through HTML, and interactive programming protocols, the author of a 
particular Web page(s) is able to make information available to viewers of the 
Web page(s) by placing the Web page(s) on an Internet Web server in HTML 
format. The network path to the server is identified by a URL (Uniform Resource 
Locator) and, generally, any client running a Web browser can access the Web 
pages by the URL. 

[0014] The Web has become ubiquitous in businesses and homes because it 
has proven to be convenient for various applications, such as news and data 
delivery, conducting banking and investment transactions, and the like. The Web 
and its authoring, transmission, and display protocols, such as browsers, HTML, 
CGI (common gateway interface), Active Server Pages™, and Java™, have 
become a worldwide standard for information exchange. However, in view of the 
market considerations discussed above, and other factors, the Web has not been 
harnessed as an effective tool in managing pharmacy benefits. 

[0015] SUMMARY OF THE INVENTION 

[0016] It is clear that there is a need for providing access to pharmacy cost 
and clinical information to patients and their physicians to permit patients and 
physicians to become active participants in drug therapy decisions with cost 
factors being considered. 

[0017] A first aspect of the invention is a pharmacy benefits management 
system and method. A processor server has claim information relating to 
pharmacy benefits claims, and information relating to a claims processing 
formularly stored therein. A provider server has pharmacy benefits plan structure 
information stored therein. A management server has price information relating 
drugs in various classes and a processing module for correlating the claim 
information with the benefits plan structure information and the formularly 
information to identify drugs dispensed to patients, expenses associated with the 
drugs in accordance with the pharmacy benefits plan structure information, 
alternative drugs in the same class as the drugs and expenses associated with 
the alternative drugs. 
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[0018] BRIEF DESCRIPTION OF THE DRAWING 

[0019] The invention will be described through a preferred embodiment and 
t\)e attached Drawing in which: 

[0020] Fig. 1 is a block diagram of the computer architecture of the preferred 
embodiment; 

[0021] Fig. 2 is a flow chart of the function of the recipient module of the 
preferred embodiment: 

[0022] Fig. 3 is a first registration screen of the preferred embodiment; 

[0023] Fig. 4 is a second registration screen of the preferred embodiment; 

[0024] Fig. 5 is a third registration screen of the preferred embodiment; 

[0025] Fig. 6 is a fourth registration screen of the preferred embodiment; 

[0026] Fig. 7 is a recipient benefits summary screen of the preferred 
embodiment; 

[0027] Fig 8. Is a detailed recipient benefits screen of the preferred 
embodiment; 

[0028] Fig. 9 is a recipient alternative search screen of the preferred 
embodiment; 

[0029] Fig. 10a is a recipient alternative results screen of the preferred 
embodiment; 

[0030] Fig. 10b is another example of a recipient alternative results screen of 
the preferred embodiment; 

[0031] Fig. 11 is a recipient pharmacy benefits audit screen of the preferred 
embodiment; 

[0032] Fig. 12 is a plan sponsor selection screen of the preferred 
embodiment; 

[0033] Fig. 13 is sponsor drug utilization screen of the preferred embodiment; 

NVA174448.1 



[0034] Fig. 14 is sponsor drug class usage report screen of the preferred 
embodiment; 

[0035] Fig. 1 5 is sponsor alternative results screen of the preferred 
embodiment; 

[0036] Fig. 16 is a provider search filter screen of the preferred embodiment; 

[0037] Fig. 17 is a provider search results screen of the preferred 
embodiment; 

[0038] Fig. 18 is a provider individual benefits report screen of the preferred 
embodiment; 

[0039] Fig. 19 is a provider prescription detail screen of the preferred 
embodiment; 

[0040] Fig. 20 is a provider drug utilization report screen of the preferred 
embodiment; 

[0041] Fig. 21 is a consultant plan alternatives screen of the preferred 
embodiment; 

[0042] Fig. 22 is an example of a formulary for specific drug classes of the 
preferred embodiment; and 

[0043] Fig 23 is an example of a benefits structure of the preferred 
embodiment 

[0044] DETAILED DESCRIPTION 

[0045] Fig. 1 schematically illustrates pharmacy benefits management system 
100 of the preferred embodiment. Management server 110 is a general purpose 
computer running an operating system and Web server software such as that 
distributed under the trade name APACHE™. In the preferred embodiment, 
management server 110 includes recipient module 114, sponsor module 116, 
provider module 118, and consultant module 120 as software modules 
constituting a processor module containing the processing logic and database 
capability for effecting the pharmacy benefits management functions described 
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herein. The software modules are designated by function for the purpose of 
descriptive clarity herein. However, the modules need not be separate files or 
even separate blocks of code but can take any form of hardware and/or software 
for accomplishing the functionality described below. Management server 1 1 0 
can also include retail cost information 112 stored therein which includes the 
retail costs of various drugs. 

[0046] PBM server 120 is associated with a pharmacy claims processor and 
includes formulary information 122 specifying particular preferences of drugs in 
various drug classes. An example of formulary information 122 is illustrated in 
Fig. 22. The formulary of Fig. 22 is for a class of drugs know as Anti- 
hypertensives, including the subclasses ACE Inhibitors and Adrenic Antagonists 
and lists Tier 1 , Tier 2, and Tier 3 drugs in each class. PBM server 120 can be a 
general purpose computer and is coupled to management server 110 through 
communications channel 128. PBM server 120 also includes benefit information 
124 relating to pharmacy benefits provided to recipients, such as the type of drug 
dispensed, the copayment for the drug, the total cost of the drug, the identity of 
the pharmacy dispensing the drug, the identity of the doctor dispensing the drug, 
and the like. 

[0047] Provider server 130 is associated with a pharmacy benefits provider 
such as an insurance company, HMO, self insured employer, or the like. 
Provider server 130 can be a general purpose computer and is coupled to 
management server 110 through communications channel 138. Further, benefits 
server 130 includes benefits structure information 134 indicating the pharmacy 
benefits provided to each recipient of the various benefits plans administered by 
the benefits provider. For example, benefits structure information 134 can 
include the deductible for pharmacy benefits to be paid by recipient prior to 
receiving pharmacy benefits, and the copayment for each tier of drugs to be paid 
by recipient. An example of benefits structure information 132 is illustrated in 
Fig. 23 and indicates the plan copayment for each tier of drugs in the formulary. 
Such a variable copayment format is referred to as a "multi-tier" plan herein. 



NVA174448.1 



[0048] Additionally, recipient client 140 and sponsor client 150 can be 
associated with a pharmacy benefit recipient (e.g. a patient, head of household, 
or other designee) and a plan sponsor (e.g. an employer) respectively and can 
be coupled to management server 110 through communication channels 148 and 
158 respectively. Recipient client 140 and sponsor client 150 can each be a 
general purpose computer running standard client software, such as Internet 
browser software. 

[0049] The primary functionality of recipient module 1 14 will be described 
below with reference to Fig. 2. When a pharmacy benefits recipient logs onto 
management server 110 through recipient client 140, recipient can access a 
wealth of information processed by management server 110. Of course access 
to information is restricted to the proper entities based on secure log in 
procedures and access privileges. 

[0050] When using system 100 for the first time, recipient, i.e.. the patient 
receiving a pharmacy benefit or their designee such as a parent or other 
guardian, accesses management server 110 through recipient client 140 and 
communication channel 148. Communication channel 148 can be an HTTP 
compliant channel, such as the Internet (including a dial up or other connection 
through an Internet service provider) or any other type of communication 
channel, such as an intranet, local are network, wide are network, or the like. 
Once establishing a connection between recipient client 140 and management 
server 1 10, it is determined whether recipient is registered for access to 
management server 1 10 in step 200. This determination can be made using 
conventional means, such as having the user select a "register" button or a 
"login" button, by identifying the user using cookies or the like, or in any other 
manner. 

[0051] If recipient is registered, the procedure advances to step 210 after the 
recipient enters identifying information, such as a username and ID. Once again, 
this can be accomplished through manual entry, use of a cookie, or in any other 
manner. If recipient is not registered, i.e. is a first time user, the procedure goes 
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to step 220 in which recipient enters the identity of the plan sponsor, such as 
recipient's employer in the case of an employer sponsored pharmacy benefits 
plan. Fig. 3 illustrates a screen displayed on recipient client 140 for entering the 
plan sponsor identity. As illustrated in Fig. 3, recipient can be prompted to enter 
the first several letters of the sponsor's name in field 222. After entering the first 
several, e.g. first two, letters of the sponsor's name, and selecting "continue" 
button 224, recipient is presented with the search results illustrated in Fig. 4 in 
which all plan sponsors corresponding to the entered letters that are part of 
system 100 are displayed as hypertext links in column 226 with the 
corresponding city of the plan sponsor in column 228. 

[0052] Recipient then selects their plan sponsor from the list of search results, 
to determine which benefits plan the recipient is subject to, and is taken tothe 
screen illustrated in Fig. 5 for entry of recipient personal information. For 
example, recipient can be prompted to enter the name of the plan subscriber in 
field 232 (i.e., the name of the employee or other person subscribing to the 
pharmacy benefits plan), pharmacy benefits plan number in field 234, recipients 
name in fields 236 and 238, recipient date of birth in field 242, recipients 
individual coverage number in field 244, and an email address of recipient or plan 
subscriber in field 246. Of course, any personal information required or desired 
for use of system 10 can be requested and entered. Selecting button 248 
causes display of the screen illustrated in Fig. 6 in which recipient is permitted to 
select, or change the status of, previously registered family members who can 
view recipient's pharmacy benefits information. For example, recipient may be a 
child or spouse who wishes to let their parent or spouse, or other member of the 
family, view their data. Accordingly, the term "recipient" as used herein refers to 
the person receiving the pharmacy benefit or the designee of that person for 
viewing pharmacy benefits information. Table 252 illustrates the current 
permission status of each member of recipient's family, i.e., authorized or not 
authorized for viewing recipient's data. Drop down menus 254 and 256 can be 
used to select family members and change their authorization status. 
Accordingly, each individual recipient has control over their own data. Preset 
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rules regarding the legal age of consent and the like can be incorporated into the 
registration process to conform to current local legal standards and the like. 

[^053] This completes the registration process of step 220 (Fig. 2), takes 
recipient to step 210 (Fig. 2), and displays the screen illustrated in Fig. 7 on 
recipient client 140. The screen illustrated in Fig. 7 displays a pharmacy benefits 
summary of recipient just registered or logged in. The summary includes out of 
pocket costs 258 for the appropriate time period (such as the current calendar 
year) and sponsor costs 262 assumed by the plan sponsor for recipient's 
pharmacy benefits for that same time period. This tool is the recipient's first look 
at the portion of the pharmacy benefit born by the plan sponsor and in and of 
itself is a powerful tool for managing pharmacy benefits because it raises the 
consciousness of recipient The summary data is culled from data available 
from PBM Server 120 through communication channel 128. Communication 
channel 128 can be an HTTP compliant channel, such as the Internet (including 
a dial up or other connection through an Internet service provider) or any other 
type of communication channel, such as an intranet, local are network, wide are 
network, or the like. In particular as noted above, PBM server 120 includes 
benefit information 124 relating to pharmacy benefits provided to recipients, such 
as the type of drug dispensed, the identity of the pharmacy dispensing the drug, 
the identity of the doctor dispensing the drug, and the like. Also, PBM server 120 
includes formulary information 122. This information can be processed by 
management server 1 10 to present out of pocket costs 258 and sponsor costs 
252. 

[0054] ...Selecting button 264 will advance the procedure to step 230 in which 
pharmacy benefits are displayed for the time period in detail. Note that recipient 
can be prompted to view their own benefits or those of another family member 
who has authorized them to view data by selecting one of a plurality of buttons or 
the like. The screen illustrated in Fig. 8. provides a list of each drug dispensed to 
recipient (as an individual) under the pharmacy benefit plan in column 266 as 
well as the date of dispensing in column 272, the recipient's out of pocket costs 
(such as copayment) for that drug in column 274, and the plan sponsor costs in 
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column 276. Once again, this information is culled from benefit information 124 
stored in PBM server 120 and processed by management server 1 10 for 
presentation on recipient client 140. Selecting "view detail" in column 264 will 
provide information relating to the corresponding drug in column 266, such as the 
drug monograph, drug to drug interactions, and other related information that is 
well know and can be obtained from various sources. Pharmacy benefits from 
previous period, such as the last year can be accessed by selecting button 278. 

[0055] System 100 has thus provided recipient with cost information to which 
recipient most likely never had access to before. Accordingly, recipient is more 
educated with respect costs of their pharmacy benefit. However, it is desirable 
that recipient, as a consumer, be presented with cost saving alternatives in order 
to close the loop in management of the pharmacy benefits provided to recipient. 
Accordingly, upon request by recipient, the procedure can proceed to step 240 
(Fig. 2) and the screen illustrated in Fig. 9 can be displayed on recipient client 
140. Drop down menu 282 permits recipient to select any one of the drugs 
dispensed to recipient for the purpose of comparing therapeutic alternatives. A 
separate drug lookup function can be provided for comparison of alternatives to 
drugs not dispensed pursuant to the pharmacy benefit or otherwise not on the list 
provided by system 100 for the recipient. The desired quantity for comparison is 
entered in field 284, and the recipient selects button 286 to proceed to display of 
the screen illustrated in Fig. 10a. 

[0056] In this example, recipient has selected "ACIPHEX 20 MG TABLET EC" 
for comparison with therapeutic alternatives and thus this drug is highlighted in 
column 288 which lists the alternative drugs. Column 292 displays the retail cost 
of each drug based on retail cost information 1 12 stored in management server 
110. Column 294 lists the retail out of pocket costs for each drug for the recipient 
based on benefits structure information 132 stored in provider server 130. 
Column 296 lists the mail order or other alternative distribution chain out of 
pocket expense for each drug based on benefits structure information 132 
stored in provider server 130. Of course, some pharmacy benefits plans will not 
include an alternative distribution option and, in such a case, column 296 can be 



NVA174448.1 



- 12- 



left blank or omitted entirely. Significantly, it can be seen_that the out of pocket 
costs for "PRILOSEC 20 MG CAPSULE DR" would have been significantly less, 
i.e., ten dollars as opposed to twenty-five dollars, in this example than the actual 
out of pocket costs for the drug that was dispensed. Of course, recipient alone 
cannot make the determination of which drugs to take. However, recipient can 
take the information presented in the screen of Fig. 10a to his doctor and, if the 
doctor agrees it is appropriate, the doctor can write a prescription for the specific 
medication indicated as most cost effective. Accordingly, recipient has been 
provided with the tools, i.e. the necessary information, to make an informed 
choice of medication, along with his doctor, based on price, efficacy, and safety. 
As an example, recipient client 140 can be a portable computer or other 
computer located in the doctor's office to permit decisions to be made prior to 
writing a prescription. 

[0057] Fig. 1 0b is another example of a therapeutic alternative list generated 
by the preferred embodiment and has columns similar to Fig. 10b labeled with 
like reference numerals. In this example, recipient has selected "ZESTRIL 40MG 
TABLET" for comparison with therapeutic alternatives and thus this drug is 
highlighted in column 288 which lists the alternative drugs. Column 292 displays 
the retail cost of each drug based on retail cost information 112 stored in 
management server 110. Column 294 lists the retail out of pocket costs for each 
drug for the recipient based on benefits structure information 132 stored in 
provider server 130. Column 296 lists the mail order or other alternative 
distribution chain out of pocket expense for each drug based on benefits 
structure information 132 stored in provider server 130. In this example, it can 
be seen that the out of pocket costs for "PRINIVIL 40MG TABLETS" would have 
been significantly less, i.e., ten dollars as opposed to twenty-five dollars, than the 
actual out of pocket costs for ZESTRIL. Further, the total cost for PRINIVIL is 
also less than that for ZESTRIL. Finally, it is significant to note that these drugs 
are the same drug marketed under different trade names. This illustrates the 
anomalies associated with the use of formularies and multi-tier benefits 
structures and how these anomalies result in increased costs without the proper 
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analysis and management Once again, Recipient can take the information 
presented in the screen of Fig. 10b to his doctor and, if the doctor agrees it is 
appropriate, the doctor can write a prescription for the specific medication 
indicated as most cost effective, 

[0058] Recipient can at any time request to conduct a pharmacy benefits 
audit, i.e. to examine and verify pharmacy benefits that they have received. A 
great deal of costs are wasted because of errors in processing claims, 
prescriptions never picked up by recipient and the like. Previously, a great deal 
of expense was incurred in attempting to recover such costs by conducting audits 
of a small percentage of processed pharmacy benefits claims. Of course, it is 
too onerous to audit all claims. By selecting the audit provision of system 100, 
recipient is taken to step 250 (Fig. 2) and the screen illustrated in Fig. 11 is 
displayed. Column 292 lists the name of each drug provided pursuant to the 
drug benefit and includes drop down menus for verifying whether the drug of that 
name was received by recipient by selection of "yes" or "no" from the menu. 
Column 294 lists the date each drug was dispensed by the pharmacy pursuant to 
the drug benefit and includes drop down menus for verifying whether the drug 
was received by recipient on or about that date by selection of "yes" or "no" from 
the menu. Column 296 lists the quantity of each drug provided pursuant to the 
drug benefit and includes drop down menus for verifying whether the quantity of 
the drug of that name was received by recipient by selection of "yes" or "no" from 
the menu. Column 298 lists the payment, i.e. out of pocket costs, for each drug 
provided pursuant to the drug benefit and includes drop down menus for verifying 
whether the proper payment was made by recipient. Buttons 302 and 304 can 
be selected for submitting recipient audit responses to management server 110 
or skipping step 250 respectively. When submitted, recipient audit information 
can be utilized by the plan sponsor, care manager, or other parties for the 
purpose of auditing claims processed by the PBM or other claims processor. 

[0059] As indicated by the arrows in Fig. 2, the various steps of recipient 
module 1 12 can be accomplished in any order and can be accomplished 
independently or in combination with other steps. However, ordinarily, the 
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registration or login steps will be conducted prior to other steps. 

[0060] Plan sponsor module 1 16 of management server 1 10 can be accessed 
by a plan sponsor, such as an employer or other entity paying for plan benefits, 
via sponsor client 150 and communications channel 158. Communications 
channel 158 can be an HTTP compliant channel, such as the Internet (including 
a dial up or other connection through an Internet service provider) or any other 
type of communication channel, such as an intranet, local area network, wide 
area network, or the like. Of course, as the entity paying for pharmacy benefits, 
plan sponsor has a great interest in controlling costs through pharmacy benefits 
management. However, in the case of plan sponsor being an employer, plan 
sponsor may not want to view, and in fact may be legally prohibited from viewing, 
pharmacy benefits data for individuals. For example, knowledge of the 
medication taken by employees could be used to discriminate against certain 
employees or at least create the potential appearance of such discrimination. 
Accordingly, plan sponsor module 114 of the preferred embodiment provides 
aggregate data that is useful to the plan sponsor but avoids the individual data 
described above with respect to recipient module 112. 

[0061] After a login and/or registration procedure that can be similar to that 
described above with respect to recipient module 112, and which is adequate to 
identify plan sponsor, plan sponsor is presented with the screen illustrated in Fig. 
12. Radio button 310 permits plan sponsor to select a drug utilization report 
aggregated by drug class. Radio buttons 312 permit selection of any one of a 
number of reports as indicated. Fields 306 and 308 permit the selection of 
rejevant start and end dates respectively for any reports. . If plan sponsor selects 
radio button 310 and selects button 314, utilization statistics are displayed on 
plan sponsor client 150 as illustrated in Fig. 13. The utilization statistics are 
grouped by drug classes as indicated in column 316 (as hypertext links). For 
each drug class, the statistics provide the total payment by the pharmacy plan 
provider for that class in column 318, the percentage of plan payment for that 
class as compared to total expenditures under the plan for pharmacy benefits in 
column 320, the total out of pocket payment for recipients for that drug class in 



NVA174448.1 



- 15- 



column 322 and the percentage of out of pocket payment for that class as 
compared to total recipient out of pocket payment under the plan for pharmacy 
benefits in column 324. Of course, this information provides plan sponsor with 
an overview of where the pharmacy benefit expenditures are going. Further, 
plan sponsor can "drill down" in each drug class to obtain additional information. 
For example, if plan sponsor selects "selective serotonin reuptake inhibitors," 
The screen illustrated in Fig. 14 is displayed on sponsor client 150. 

[0062] In Fig. 14, plan sponsor can view detailed information for each drug in 
the selected class as indicted in column 326. Specifically, sponsor can view the 
total payment by the pharmacy benefits plan for each brand name of a drug in 
column 328, the percentage of plan payment for that brand name as compared to 
total expenditures under the plan for the class in column 330, the total out of 
pocket payment for recipients for that drug in column 332 and the percentage of 
out of pocket payment for that drug as compared to total recipient out of pocket 
payment under for the class in column 324. 

[0063] Plan sponsor can enter a desired quantity of any particular drug in field 
336 and select button 338 to produce sponsor therapeutic alternative report as 
illustrated in Fig. 15. Column 336 lists the alternative drugs as hypertext links. 
Column 338 displays the retail cost of each drug based on retail cost information 
112 stored in management server 110. Column 340 lists the out of pocket 
copayment for each alternative in accordance with formularly information 122 
and benefits structure information 134. This tool permits sponsor to perform 
cost/benefit analysis for each drug based on rebate information that is available 
from the pharmacy benefit manager such as the PBM. For example, as seen in 
Fig. 14, in this example, the largest expenditures in this class were for 
PROZAC™. However, PROZAC™ is the third least expensive drug in the class. 
Possibly, rebates from the benefits manager for PROZAC™ overcome this cost 
differential. However, the burden can be placed on the benefits manager to 
demonstrate this fact. Alternatively, rebate information could be imported into 
system 1 00 and utilized to generate such an analysis automatically. 
Accordingly, plan sponsor has the information required to make an informed 
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choice of benefits and can request a change in formularly by the pharmacy 
benefits manager, or other claims processor, with the negotiating power of the 
relevant information. 

[0064] Provider module 118 provides various tools designed for the benefits 
provider, e.g. an insurance company or HMO, is illustrated in Fig. 16. Buttons 
342 through 356 correspond to predetermined search criterion as indicated. The 
search criterion are designed to identify patients that are at high risk for use of 
pharmacy benefits and thus whose care should be managed most closely. Of 
course, the criterion can be changed to identify any particular group of recipients. 
For example, if button 350 is selected, the screen illustrated in Fig. 17 is 
displayed on manager client 130. This screen illustrates the recipient IDs for 
recipients fitting the filter in column 358, i.e recipients taking anti-hypertensives 
and diabetes medication. 

[0065] By selecting the recipient ID, plan manager can drill down to the 
pharmacy benefits for that recipient, as illustrated in Fig. 18, which provides a list 
of each drug dispensed to recipient (as an individual) under the pharmacy benefit 
plan in column 360 as well as the date of dispensing in column 362, the 
recipient's copayment for that drug in column 364, and the plan sponsor costs in 
column 366. Once again, this information is culled from benefit information 124 
stored in PBM server 120 and processed by management server 1 10 for 
presentation on recipient client 140. This information permits plan sponsor to 
police for possible adverse drug to drug interactions, use the date filled to see if 
the recipient is generally complying with doctor's orders, e.g. taking medication 
rejgularly when appropriate, monitor total costs to make sure recipients do not 
reach total benefit costs prematurely, and the like. Selecting "view detail" in 
column 368 will provide prescriber and pharmacy information as illustrated in Fig. 
19 to permit detection of the use of plural doctors and pharmacies to obtain over 
doses of specific drugs and the like. 

[0066] Consultant module 120 includes processing functionality that is 
specifically helpful to consultants in analyzing and constructing pharmacy benefit 
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pans. Consultants using consultant module 120 can be contractors hired as 
consultant or in-house consultants of plan sponsor, plan provider, or another 
party. Accordingly, no particular party's computer is associated with consultants 
in the preferred embodiment. Consultant module 120 permits consultant to 
select a particular pharmacy benefits plan to display drug utilization of that plan 
by drug class as illustrated in Fig. 20. For each drug class in column 370, the 
statistics provide the total payment by the pharmacy benefits plan for that class in 
column 372, the percentage of plan payment for that class as compared to total 
expenditures under the plan for pharmacy benefits in column 374, the total out of 
pocket payment for recipients for that drug class in column 376, and the 
percentage of out of pocket payment for that class as compared to total recipient 
out of pocket payment under the plan for pharmacy benefits in column 378. 

[0067] By selecting a drug class from column 370, model formularies and plan 
benefits can be compared for cost benefits using the screen illustrated in Fig. 21 . 
Field 380 illustrates the sponsor cost, recipient cost and total cost for drugs in the 
selected drug class for the selected plan. Once again, this information is 
compiled from retail price information 1 12, formularly information 124, and benefit 
structure information 134. Field 382 displays plan benefits model data based on 
behavior hypothesis information entered by consultant as described below. In 
other words, field 382 presents a "what if scenario for the entered proposed 
modifications. For example, in field 384, consultant can select an existing plan 
drug and a proposed new replacement drug (therapeutic equivalent) as well as a 
desired percentage of migration within the plan form the existing drug to the 
proposed drug. This will result in a change of total costs reflected in field 382. 
Similarly Jn field 386, consultant can change the proposed levels of copayments 
or coinsurance percentage and, in field 388, the consultant can change 
copayment amounts of the benefits structure to see how costs are affected in 
field 382. 

[0068] It can be seen that the preferred embodiment provides powerful tools 
for managing many aspects of a pharmacy benefit plan. The preferred 
embodiment processes information from the plan benefits structure and the plan 
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formulary in a novel way to provide alternative costs and pther information. Any 
type of computer architecture can be utilized in connection with the invention. 
The various servers and clients of the preferred embodiment can each comprise 
plural devices or can be consolidated with one another. Accordingly, the term 
"computer" as used herein refers to any device or devices capable of the 
disclosed processing and/or display functions. For example, the various servers 
and clients can be personal computers, mini computers, hand-held devices such 
as PDAs, thin clients, Internet appliances, or the like. 

[0069] In the preferred embodiment, the communication channels are the 
Internet and related access links. However, the communication channels can 
take any form and use any appropriate protocols. For example the 
communication channels can be cables, wireless transmitters and receivers, 
optical devices. Or the like. The communication channels can be part of an 
intranet, LAN, WAN, or other network. All of the disclosed computers can be in a 
single location and the communication channels can be local busses such as 
serial busses, Universal serial busses, parallel busses, or the like. The various 
displays and data can be modified to provide the desired tools. The logic of the 
invention can be accomplished through any programming language, through 
hardwired devices, or through any other processing device. The various 
modules may take any form of software and/or hardware and need not be distinct 
form one another. The computers and other devices can have any type of 
memory devices for storing the desired information, such as magnetic hard 
drives, CD ROM drives, and the like. Of course, the computers can have any 
appropriate display devices and data input devices and can use any appropriate 
user interface. Of course, a display can be a CRT, LCD, printer, or any other 
device capable of presenting information. The various information can be 
downloaded in any manner such as through a database query, a file transfer, or 
the like and thus the term "download" as used herein refers broadly to any 
transfer of data and can be accomlished in real time, or in advance of when the 
data is needed. 

[0070] The invention has been described through a preferred embodiment, 
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however various modifications can be made without departing from the scope of 
the invention as defined by the appended claims and legal equivalents thereof. 
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